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EDGE PROFILING FOR EXECUTABLE PROGRAM CODE 
HAVING BRANCHES THROUGH STUB CODE SEGMENTS 

1 

2 FIELD OF THE INVENTION 

3 The present invention generally relates to instrumentation of computer program 

4 code, and more particularly to profiling execution characteristics of a binary executable 

5 program having branches through stub code segments. 
6 

7 BACKGROUND 

8 Executable computer programs include branch instructions that when executed 

9 direct program control to target addresses in the program. In some cases, branch 

10 instructions are used to transfer control to a code segment that implements a source-code 

1 1 defined function. For example, if the source code sets forth a "function" that averages an 

12 input list of values, the function may be invoked by name in the source code. The 

13 executable code includes a target code segment that implements the function and branch 

14 instructions having target addresses that reference the target code segment. It will be 

15 appreciated that different languages have different names for functions such as procedure, 

16 routine, or method, 

17 Binary executable programs are "instrumented" or "profiled" to analyze program 

1 8 performance. The performance data that are gathered can be used to determine which 

1 9 source code might benefit most from improved coding. For example, if a particular 

20 function is called within a program loop and the loop is a hot spot during execution, it may 

21 be desirable to program the function in-line within the loop rather than as a function call. 

22 A function call may either reference a target function in the same load module, or 

23 in a different load module. From the developer's perspective, the source code does not 
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1 reference load modules. Where a function call references a function in another load 

2 module, the code generation and linking phase establishes a stub code segment that is 

3 targeted by a first branch instruction. The stub code segment obtains the address of the 

4 entry point of the target function in the other load module and then branches to the target. 

5 Since the stub code segments are typically not directly associated with any particular lines 

6 of the source code, the correlation of execution profile information with the source code 

7 can be difficult. 

8 A method and apparatus that address the aforementioned problems, as well as other 

9 related problems, are therefore desirable. 

10 

11 SUMMARY OF THE INVENTION 

12 The invention provides profiling of branches that pass through stub code 

13 segments in executable program code. The compilation and linking of a computer 

14 program sometimes generates stub code segments that implement the transfer of control to 

15 functions that are external to a local segment of code. Branches through the stub code 

16 segments hinder the analysis of the corresponding edges relative to the source code. In 

17 various embodiments of the invention, edges are created to represent respective branch 

18 instructions in the executable program code. Each edge has a source attribute, a target 

19 attribute, and an edge-taken count attribute. During execution, the numbers of times edges 

20 are taken are counted, and stub entry points and stub targets are identified. For each edge 

21 having a target that matches an entry point of a stub code segment, the edge target is 

22 changed to the stub target associated with the matching entry point. By identifying edges 

23 that target stub code segments, edges that target stub code segments can be combined with 

24 other edges for correlation with the source code. 
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1 Various example embodiments are set forth in the Detailed Description and Claims 

2 which follow. 

3 

4 BRIEF DESCRIPTION OF THE DRAWINGS 

5 Various aspects and advantages of the invention will become apparent upon review 

6 of the following detailed description and upon reference to the drawings in which: 

7 FIG. 1 A illustrates one or more source code modules including a function call; 

8 FIG. IB illustrates executable program code in which a source code function call is 

9 translated into branches through stub code segments to the binary code that implements 

10 the function; 

1 1 FIG. 2 illustrates an example stub map table that maps stub entry point addresses to 

12 the target addresses of the stub code segments; 

13 FIG. 3 is a flowchart of a process for profiling edges of executable program code 

14 in accordance with one embodiment of the invention; and 

15 FIG. 4 is a flowchart of an example process for reporting edge profile data. 
16 

n DETAILED DESCRIPTION 

1 8 In various embodiments, the invention profiles program execution by gathering 

19 execution counts of edges that represent a non-sequential transfer of control in the 

20 executable program and collapsing edges associated with stub code segments into edges 

21 that can be correlated with the source program. An edge symbolizes a control path in an 

22 executable program, and the number of times an edge is taken in executing the program 

23 may provide useful information for analyzing and improving program performance. In an 

24 example embodiment, edges are associated with branch instructions, and each edge has a 

25 source address (the address of the instruction) and a target address (the target address of 
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1 the instruction). In another embodiment, edges have other attributes such as a weight 

2 attribute. Along with accumulating numbers of times edges are taken, the stub code 

3 segments that are executed are identified. In reporting edge execution frequencies, the 

4 identified stub code segments are used to correlate the edges with source code statements. 

5 FIG. 1 A illustrates one or more source code modules including a function call. 

6 Source code 102 is an example computer program written in a language such as C, C++ or 

7 any of a variety of other compiled languages. The source code includes the function foo() 

8 106, which is called from elsewhere in the source code as shown by reference number 108. 

9 Line 110 represents an edge of the source code, with the source of the edge being at call 

10 fooO (ref. 1 10) and the target of the edge being at the entry point of fooO 106. Function 

1 1 fooO calls barQ, which is represented as edge 111. Edges are useful in analyzing program 

12 performance because they can indicate not only the number of times a function was 

13 executed, but also the points in the program from which the function was called, as a 

14 function may be invoked from many different locations in the program. 

15 FIG. IB illustrates executable program code in which a source code function call 

16 has been compiled and linked into branches through stub code segments to the binary code 

17 that implements the function. Executable program code 1 12 is generated from 

18 compilation and linking of example source code 102. Branch instruction 1 14 corresponds 

19 to the source code statement call fooQ 108. However, in the example branch 11 1 14 

20 branches to 11 (1 1 6), at which a stub code segment is located. 

21 Stub code segments are generated in the compilation/linking process in a number 

22 of situations. For example, if the target code is in another load module, a stub code 

23 segment is generated to perform operations such as obtaining the address of the target 

24 entry point and the value of the global pointer from the linkage tables before branching to 

25 the target. Stub code segments are also generated to bridge an addressing distance 
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1 between the source and the target if the target cannot be reached by an instruction pointer 

2 relative branch instruction. In another example, stub code segments are used in branching 

3 by reference to an alias of a function name. For example, a stub code segment links a call 

4 foojQ to the code for fooQ. 

5 In some situations, there are branches through multiple stub code segments before 

6 reaching the target function, as illustrated by the stub code segments at labels // and 12 

7 (118). The executable code for the function fooO is at label 13 (120) in the example. 

8 In the example executable program code 1 12, the call fooO statement is 

9 implemented with branches through the two stub code segments at 11 and 12. The first 

10 branch instruction 1 14 branches to 11, the stub code at 11 branches to the stub code at 12, 

1 1 and the stub code at 12 branches to 13 9 which is the code for fooQ. 

12 Three example edges 130, 1 32, and 134 are illustrated in the executable program 

13 code 1 12 for passing control from branch 1 14 to the code for foo(). Edge 136 represents 

14 the call to the function bar() from foo(). Since the stub code is generated in the 

15 compilation/linking of the source code and the executable does not have information that 

16 correlates the stub code to corresponding source code line numbers, analyzing control flow 

17 from the branch 1 14 to code for fooQ at label 13 is difficult. From a developer's point of 

1 8 view, execution information pertaining to edge 1 1 0 is useful for analysis. However, edge 

19 110 corresponds to edges 130, 132, and 134 in the executable program code 1 12. Since 

20 the stub code at 11 and 12 is not directly related to any source code, analyzing execution of 

21 the program and correlating the execution information of edges 1 30, 1 32, and 1 34 with the 

22 source code 102 can be difficult. 

23 In various embodiments of the invention, the stub entry points and stub targets are 

24 identified and saved. The stub entry points and stub targets are then used when reporting 

25 to correlate edge-taken frequencies with the source code. 
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1 FIG. 2 illustrates an example stub map table 150 that is used to map stub entry 

2 point addresses to the target addresses of the stub code segments. Even though addresses 

3 of the stub entry points and stub targets in the executable program are stored in the stub 

4 map table, table 150 is shown with the labels of the stub entry points and targets for 

5 purposes of illustration. Using the example of FIG. IB, the stub code at label 11 has its 

6 entry point // mapped to the target of its stub code, 12. Similarly, the stub code at label 12 

7 has its entry point 12 mapped to the target of its stub code, 13. The stub map table is used 

8 to trace edges through stub code segments to code that is not a stub, for example, the 

9 faction fooQ. By tracing the edges through the stub map table, the execution information 

10 associated with the edges 130, 132, and 134 can be correlated to the source code 102 with 

1 1 edge 110 having a source at the call fooQ statement and a target at the entry point of foo() . 

12 FIG. 3 is a flowchart of a process for profiling edges of executable program code 

13 in accordance with one embodiment of the invention. At step 300, the source code is 

14 compiled and linked using the "profile" compiler option. The profile option creates a line 

15 table that associates lines of source code with corresponding instruction addresses in the 

16 executable program code. 

17 At step 302, the profiler process attaches to a target executable application and 

1 8 obtains control. Those skilled in the art will appreciate that this step can be accomplished 

19 using known, conventional techniques. For example, in one embodiment the profiler 

20 process is part of an instrumentation tool. 

21 At step 304, the function and stub entry points are patched with breakpoints, and 

22 the replaced instructions are saved for restoring later in the process. An example method 

23 for identifying function entry points is described in the patents/applications entitled, 

24 "COMPILER-BASED CHECKPOINTING FOR SUPPORT OF ERROR RECOVERY", 

25 by Thompson et al., filed on October 3 1 , 2000, and having patent/application number 
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1 09/702,590, and "ANALYSIS OF EXECUTABLE PROGRAM CODE USING 

2 COMPILER-GENERATED FUNCITON ENTRY POINTS AND ENDPOINTS WITH 

3 OTHER SOURCES OF FUNCTION ENTRY POINTS AND ENDPOINTS", by Hundt et 

4 al., filed on April 11, 2001, and having patent/application number 09/833,249. The 

5 contents of both patents/applications are hereby incorporated by reference. Both functions 

6 and stub code segments can be identified by reference to the compiler-generated symbol 

7 table (not shown). Alternatively, the targets of branch instructions are analyzed with 

8 pattern matching for different types of stub code segments. At step 306, control is 

9 returned to the executable program. 

I o Upon encountering a breakpoint, for example, at the entry point of a function or 

I I stub code, control is returned to the profiler process and step 308. At step 308, the code 

12 that follows the breakpoint in the executable program is analyzed for stub code. Decision 

13 step 310 directs the process to step 3 12 if stub code is found. 

14 At step 312, the target of the stub code is determined from the stub code. The 

15 address of the breakpoint and the target of the stub code are stored in stub map table 150 at 

1 6 step 314. At step 3 1 6, the instruction that was saved at step 3 04 when replaced by the 

17 breakpoint is restored to the stub code. The process then returns to step 306 to continue 

1 8 execution of the executable program code. 

19 If stub code is not found following the encountered breakpoint, decision step 310 

20 directs the process to step 3 1 8. At step 3 1 8, the process identifies edges in the function by 

21 locating branch instructions. Since breakpoints were placed at the entry points of stub code 

22 segments and functions only, if the code is not stub code, the code following the 

23 breakpoint is a function. For example, in the code for fooO at 13 in FIG. IB, the branch 14 

24 instruction is used as the source of edge 136. At step 322, the function is replaced with an 

25 instrumented version (foo'O) having probe code. The probe code increments the edge- 
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1 taken counts for all edges in the function. For example, the edge-taken count is 

2 incremented for edge 136 when the corresponding probe code in foo'()is executed. (FIG. 

3 IB). One approach to dynamically instrumenting functions of a program is described in 

4 the U.S. patent application entitled, "Dynamic Instrumentation of an Executable 

5 Program", by Hundt et al. 5 filed on April 1 1 , 2001 , and having patent/application number 

6 09/833,248, which is assigned to the assignee of the present invention and incorporated 

7 herein by reference. 

8 At step 324, the breakpoint at the entry point of the function is replaced with a 

9 branch to the newly instrumented version of the function. The process then returns to step 

10 310 where control is returned to the executable program. 

1 1 FIG. 4 is a flowchart of a process for reporting edge profile data in accordance 

12 with one embodiment of the invention. The process uses the stub map table 150 to 

13 correlate edges through stub code segments with the source code. While there are more 

14 edges to process, decision step 502 directs the process to step 504 to get an edge to 

15 process. 

16 If the target of the edge is the entry point of a stub in the stub map table 1 50, the 

17 process is directed to step 508. The edge target is replaced with the target associated with 

18 the matching stub entry point from the stub map table. The process is then directed to 

19 decision step 506 to check whether the new target of the edge is a stub entry point. Steps 

20 506 and 508 are repeated until the target of the edge does not match a stub entry point in 

2 1 the table. The process is then directed to step 510. 

22 At step 5 1 0, the edge source and the edge target are correlated with lines of source 

23 code using the line table from step 300 of FIG. 3, for example. At step 512, the edge- 

24 taken count of the edge is reported in association with the source code line numbers for the 

25 edge source and the edge target. The process is then directed to decision step 502 to 
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1 determine whether there are more edges to process. When the edge-taken counts of all the 

2 edges have been reported, the process is complete. 

3 In addition to the various aspects and embodiments of the invention specifically 

4 mentioned, others will be apparent to those skilled in the art from consideration of the 

5 specification and practice of the invention disclosed herein. It is intended that the 

6 specification and illustrated embodiments be considered as examples only, with a true 

7 scope and spirit of the invention being indicated by the following claims. 
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